Etiqueta: php

  • Capas invisibles de seguridad en PHP que bloquean ataques

    Capas invisibles de seguridad en PHP que bloquean ataques

    Resumen: las “capas invisibles” son defensas integradas en el runtime o en la capa infraestrutural que bloquean clases completas de ataques antes de que lleguen al negocio. Este artículo describe seis capas prácticas y muestra ejemplos de implementación en PHP.

    Introducción

    Los atacantes buscan huecos repetibles y fáciles: salidas sin escapar, sesiones que no cambian, consultas sin parámetros. Las capas invisibles obligan al runtime o a la infraestructura a aplicar defensas por defecto, reduciendo la carga mental del desarrollador y cerrando vectores comunes.

    Prerrequisitos

    Antes de integrar estas capas conviene contar con un entorno que permita soluciones como hashing moderno, plantillas con auto-escaping y mecanismos de almacenamiento para límites por IP.

    • PHP con soporte para Argon2id (mencionado en el texto base).
    • Motor de plantillas con auto-escaping (por ejemplo, Twig o Blade, o equivalente).
    • Acceso a la base de datos vía ORM o biblioteca que permita prepared statements.
    • Sistema de caché o store (Redis, memcached, etc.) para rate-limiting y rotación de tokens.

    Desarrollo

    Procedimiento

    Capa 1 — Auto-escaping a nivel de motor de plantillas: configure el motor para escapar por defecto las salidas. Así, incluso si un desarrollador olvida sanitizar una variable, el motor evita XSS a la salida.

    Capa 2 — Hashing memory-hard para credenciales: use algoritmos que consuman memoria (Argon2id o scrypt). Según el texto base, Argon2id es la opción recomendada para evitar que dumps de contraseñas sean fáciles de crackear.

    Capa 3 — Rotación automática de tokens: regenere identificadores de sesión en eventos críticos (login, elevación de privilegios) y mantenga un tiempo de validez corto para tokens expuestos.

    Capa 4 — Firewall de consultas dentro del ORM: haga que el acceso a la BD use solo consultas parametrizadas. Si el ORM obliga a parámetros, las inyecciones se eliminan en la práctica.

    Capa 5 — Middleware adaptativo a la tasa (rate-adaptive): aumente la latencia o limite intentos según patrones sospechosos. El objetivo es hacer el brute force económicamente inviable sin afectar a usuarios legítimos.

    Capa 6 — Content Security Policy (CSP): entregue cabeceras CSP estrictas para limitar fuentes de scripts, iframes y orígenes. Esto reduce el impacto de XSS y evita exfiltración desde el navegador.

    Ejemplos

    A continuación hay ejemplos concisos para poner en práctica las capas descritas.

    <?php
    // Hashing con Argon2id
    $password = 'usuario-password';
    $options = ['memory_cost' => 1<<17, 'time_cost' => 4, 'threads' => 2];
    $hash = password_hash($password, PASSWORD_ARGON2ID, $options);
    Lenguaje del código: PHP (php)

    Ejemplo de consultas parametrizadas con PDO (ORMs modernos aplican esto por defecto).

    <?php
    $stmt = $pdo->prepare('SELECT id, email FROM users WHERE email = :email');
    $stmt->execute([':email' => $email]);
    $user = $stmt->fetch();
    Lenguaje del código: PHP (php)

    Rotación de token/ID de sesión en eventos clave.

    <?php
    session_start();
    // Tras login o cambio de privilegios
    session_regenerate_id(true);
    $_SESSION['rotated_at'] = time();
    // Verificar caducidad en cada petición
    if (isset($_SESSION['rotated_at']) && time() - $_SESSION['rotated_at'] > 3600) {
        // forzar logout o revalidación
    }
    Lenguaje del código: PHP (php)

    Cabecera CSP mínima para reducir ejecución de scripts externos.

    <?php
    header("Content-Security-Policy: default-src 'self'; script-src 'self'");
    Lenguaje del código: PHP (php)

    Middleware simple para introducir fricción adaptativa en intentos de login.

    <?php
    $ip = $_SERVER['REMOTE_ADDR'];
    $attempts = $cache->get("login:{$ip}") ?? 0;
    if ($attempts > 5) {
        // añadir demora creciente (ej. usleep) para frustrar ataques automatizados
        usleep(min(500000 * ($attempts - 5), 2000000));
    }
    $cache->set("login:{$ip}", $attempts + 1, 300);
    Lenguaje del código: PHP (php)

    Checklist

    1. Habilitar auto-escaping en el motor de plantillas.
    2. Usar hashing memory-hard (Argon2id) para contraseñas.
    3. Forzar consultas parametrizadas desde el ORM o capa de datos.
    4. Implementar rotación de tokens y control de caducidad.
    5. Agregar middleware rate-adaptive para endpoints sensibles.
    6. Entregar cabeceras CSP estrictas y revisar políticas periódicamente.

    Conclusión

    Las capas invisibles eliminan vectores enteros de ataque al aplicar buenas prácticas desde el runtime y la infraestructura. Implementarlas reduce la superficie de ataque y permite a los equipos centrarse en la lógica de negocio con mayor confianza.

  • Trucos PHP para evitar picos de CPU en producción

    Trucos PHP para evitar picos de CPU en producción

    Este artículo resume tácticas prácticas y verificables para reducir picos de CPU en aplicaciones PHP en producción. Se centra en cambios puntuales: bucles, caché, extensiones y preload.

    Introducción

    Los picos de CPU suelen ser consecuencia de patrones repetitivos: bucles descontrolados, reconstrucciones de caché simultáneas, operaciones de cálculo en PHP y bloqueos que consumen ciclos. Aquí verás acciones concretas para reducir su impacto sin reescribir todo el stack.

    Prerrequisitos

    Antes de aplicar las tácticas: asegúrate de tener monitoreo de CPU y trazas, un sistema de caché (p. ej. Redis) y OPcache habilitado. Algunas recomendaciones asumen disponibilidad de extensiones (GMP/BCMath) o mecanismos de event loop si se migran procesos largos.

    opcache.enable=1
    opcache.preload=/var/www/preload.php
    Lenguaje del código: TOML, también INI (ini)

    Desarrollo

    Procedimiento

    A continuación se describen las tácticas principales, con ejemplos y recomendaciones de implementación mínima para reducir picos de CPU.

    1) Controlar bucles y procesamiento por lotes: no iteres colecciones potencialmente enormes en una sola pasada; procesa en chunks y paginación para limitar uso de CPU por iteración.

    <?php
    foreach ($users as $user) {
        process($user);
    }
    Lenguaje del código: PHP (php)
    <?php
    foreach (array_chunk($users, 500) as $batch) {
        foreach ($batch as $user) {
            process($user);
        }
    }
    Lenguaje del código: PHP (php)

    2) Caché: evita el “dogpile” (cache stampede) usando coalescencia de peticiones; solo un worker debe reconstruir el caché mientras los demás leen la versión existente.

    <?php
    if ($lock = $redis->setnx("lock:feed", 1)) {
        $redis->expire("lock:feed", 30);
        $data = buildFeed();
        $redis->set("cache:feed", $data, 300);
    } else {
        $data = $redis->get("cache:feed");
    }
    Lenguaje del código: PHP (php)

    3) Delegar cálculos pesados a extensiones o bibliotecas nativas. Para parsing/validación de JSON o aritmética de gran precisión, usar extensiones C (GMP, BCMath) reduce tiempo de CPU en PHP puro. El uso de funciones específicas (por ejemplo, json_validate() si está disponible) evita sobrecarga por manejo de excepciones.

    4) Evitar sleep() en workflows asíncronos. Reemplaza bucles con sleep por event loops (ReactPHP, Swoole) o por colas con workers que esperan con mecanismos eficientes.

    5) OPcache y preload: habilita OPcache y pre-carga clases/archivos críticos para reducir interpretación por petición y el coste del autoloader en caliente.

    <?php
    require_once __DIR__ . '/vendor/autoload.php';
    require_once __DIR__ . '/src/BigFatClass.php';
    Lenguaje del código: PHP (php)

    6) Detectar fugas ocultas de CPU: logging síncrono excesivo, regex con backtracking y operaciones I/O sin batching pueden generar picos. Prueba patrones costosos y usa loggers asíncronos o batch writers.

    Ejemplos

    Aquí hay ejemplos listos para adaptar a tus jobs o endpoints problemáticos.

    <?php
    // Antes: procesar todo en memoria (riesgo de pico)
    foreach ($users as $user) {
        process($user);
    }
    Lenguaje del código: PHP (php)
    <?php
    // Después: procesar por lotes para limitar CPU por iteración
    foreach (array_chunk($users, 500) as $batch) {
        foreach ($batch as $user) {
            process($user);
        }
    }
    Lenguaje del código: PHP (php)
    <?php
    // Coalescencia de caché en Redis
    if ($lock = $redis->setnx("lock:feed", 1)) {
        $redis->expire("lock:feed", 30);
        $data = buildFeed();
        $redis->set("cache:feed", $data, 300);
    } else {
        $data = $redis->get("cache:feed");
    }
    Lenguaje del código: PHP (php)

    Checklist

    1. Identificar endpoints/jobs con mayor CPU y trazar hot paths.
    2. Reescribir bucles para procesamiento por lotes o paginación.
    3. Implementar coalescencia de caché (lock + fallback) para evitar stampedes.
    4. Delegar cómputo pesado a extensiones nativas cuando sea posible.
    5. Habilitar OPcache y preload para reducir interpretación y autoload en cada petición.
    6. Sustituir sleep() por event loops o colas con espera eficiente.

    Conclusión

    Los picos de CPU se solucionan con disciplina operativa y correcciones puntuales: controlar bucles, proteger la caché, delegar trabajo pesado y optimizar la carga de código. Implanta las medidas gradualmente y valida con métricas.

    Pequeñas correcciones en el código y la configuración suelen eliminar los picos de CPU más rápido que reescribir todo el sistema.

  • Seguridad de sesiones y cookies en PHP: guía práctica

    Seguridad de sesiones y cookies en PHP: guía práctica

    Resumen: Esta guía práctica resume las medidas esenciales para gestionar sesiones y cookies en PHP de forma segura: inicio de sesión, regeneración de ID, cookies seguras, timeouts, almacenamiento eficiente y limpieza al cerrar sesión.

    Introducción

    Sesiones y cookies permiten mantener estado en aplicaciones web PHP: autenticación, preferencias y datos temporales. Usadas correctamente mejoran la experiencia; mal configuradas, introducen riesgos de seguridad.

    Prerrequisitos

    Antes de aplicar las prácticas descritas asegúrate de servir las páginas sensibles por HTTPS y de tener control sobre el código que inicia y destruye sesiones. No afirmaré compatibilidades concretas; valida esto según tu entorno.

    Conocimiento mínimo necesario: saber dónde llamar a session_start() y cómo enviar cookies desde PHP. Evita exponer identificadores de sesión en URLs o registros.

    Desarrollo

    Procedimiento

    Pasos prácticos y concisos para asegurar sesiones y cookies en PHP. Aplique cada paso según el riesgo y la arquitectura de su aplicación.

    1. Iniciar sesiones de forma controlada y consistente.
    2. Regenerar el identificador de sesión tras la autenticación.
    3. Enviar cookies con flags Secure, HttpOnly y SameSite cuando corresponda.
    4. Implementar timeouts por inactividad y limpieza al logout.
    5. Almacenar solo identificadores en la sesión; datos pesados en base de datos o cache.
    6. Opcional: usar un session handler personalizado para almacenamiento centralizado.

    Detalles clave: regenerar el ID reduce el riesgo de session fixation; Secure y HttpOnly protegen el cookie en tránsito y frente a JavaScript; SameSite mitiga ciertas CSRF.

    Pro tip: Usa sesiones para identificar entidades (IDs) y no para persistir grandes objetos o datos sensibles sin cifrado.

    Ejemplos

    A continuación se incluyen ejemplos prácticos adaptados desde patrones comunes. Escapa los marcadores de apertura PHP en tu código según la plantilla del bloque.

    <?php
    // Start the session
    session_start();
    
    // Store some data in the session
    $_SESSION['username'] = 'JohnDoe';
    
    // Retrieve data from the session
    echo 'Hello, ' . $_SESSION['username']; // Outputs: Hello, JohnDoe
    Lenguaje del código: PHP (php)

    Regenerar el ID de sesión inmediatamente después de un login exitoso:

    <?php
    session_start();
    
    // After a successful login
    if ($_POST['username'] == 'user' && $_POST['password'] == 'password') {
        session_regenerate_id(true);  // Regenerate the session ID for added security
        
        $_SESSION['username'] = 'user';
        echo "Login successful, and your session ID has been regenerated!";
    }
    Lenguaje del código: PHP (php)

    Ejemplo de cookie segura con atributos recomendados (transmisión segura y protección contra acceso por JS):

    <?php
    // Set a cookie that only works on secure connections (HTTPS)
    setcookie('user_preference', 'dark_mode', [
        'expires' => time() + 3600, // 1 hour expiration
        'path' => '/',
        'domain' => 'yourdomain.com',
        'secure' => true,  // Send cookie only over HTTPS
        'httponly' => true,  // Prevent JavaScript access to cookie
        'samesite' => 'Strict' // Helps prevent CSRF attacks
    ]);
    
    echo 'Your preference cookie is set securely.';
    Lenguaje del código: PHP (php)

    Timeout de sesión por inactividad (mecanismo simple basado en marcas temporales):

    <?php
    session_start();
    
    // Set timeout period (10 minutes)
    $timeout = 600;
    
    if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > $timeout)) {
        // If the session has expired, destroy it
        session_unset();
        session_destroy();
        echo 'Session expired. Please log in again.';
    } else {
        $_SESSION['LAST_ACTIVITY'] = time(); // Update last activity time
        echo 'Your session is still active.';
    }
    Lenguaje del código: PHP (php)

    Esqueleto de un session handler personalizado para almacenar sesiones en base de datos o cache centralizada:

    <?php
    class CustomSessionHandler extends SessionHandler {
        public function read($session_id) {
            // Read session data from the database
        }
    
        public function write($session_id, $data) {
            // Write session data to the database
        }
    }
    
    // Register custom session handler
    $handler = new CustomSessionHandler();
    session_set_save_handler($handler, true);
    session_start();
    Lenguaje del código: PHP (php)

    Al cerrar sesión, destruye la sesión y expira las cookies relevantes para evitar reutilización:

    <?php
    session_start();
    
    // Destroy the session and clear all session data
    session_unset();
    session_destroy();
    
    // Expire session and preference cookies
    setcookie(session_name(), '', time() - 3600, '/');
    setcookie('user_preference', '', time() - 3600, '/');
    
    echo 'Session and cookies have been cleared.';
    Lenguaje del código: PHP (php)

    Checklist

    1. Servir páginas sensibles por HTTPS.
    2. Iniciar sesión con session_start() solo donde sea necesario.
    3. Regenerar ID de sesión tras autenticación (session_regenerate_id).
    4. Enviar cookies con Secure, HttpOnly y SameSite adecuados.
    5. Implementar timeout por inactividad y actualizar LAST_ACTIVITY.
    6. Almacenar solo identificadores en la sesión; consultar DB para datos grandes.
    7. Destruir sesión y expirar cookies en logout.

    Conclusión

    La seguridad de sesiones y cookies es una combinación de buenas prácticas: transporte seguro (HTTPS), configuración correcta de cookies, rotación de identificadores, timeouts y limpieza al logout. Estas medidas reducen riesgos comunes como hijacking y XSS.

    Empieza aplicando los pasos del checklist y adapta las implementaciones (por ejemplo, handlers personalizados) según la escala y arquitectura de tu aplicación.

  • Implementar TOTP (MFA) en Symfony 7: guía práctica

    Implementar TOTP (MFA) en Symfony 7: guía práctica

    \n

    En esta guía práctica se explica cómo añadir autenticación multifactor TOTP (Time-based One-Time Password) a una aplicación Symfony 7. Incluye el servicio TOTP, cambios en la entidad, migración, controladores, formulario, suscriptor de eventos y recomendaciones de seguridad.

    \n\n\n\n\n\n\n\n

    Introducción

    \n\n\n\n

    TOTP es el estándar (RFC 6238) que usan Google Authenticator, Authy y similares. Genera códigos de un solo uso a partir de un secreto compartido y la hora actual.

    \n\n\n\n

    Esta implementación está pensada para integrarse con el sistema de autenticación de Symfony: genera secretos, muestra un QR para el usuario, verifica códigos en el login y obliga a verificar tras el login usando la sesión.

    \n\n\n\n

    Prerrequisitos

    \n\n\n\n
    • Proyecto Symfony 7 con sistema de autenticación ya configurado.
    • Doctrine ORM (para persistir el secreto).
    • Conocimientos básicos de seguridad en Symfony.
    \n\n\n\n

    Instalar la dependencia para generar QR (se usa Endroid en el ejemplo):

    \n\n\n\n
    composer require endroid/qr-code
    \n\n\n\n

    Desarrollo

    \n\n\n\n

    Procedimiento

    \n\n\n\n

    Resumen de pasos implementados en el proyecto:

    \n\n\n\n
    1. Agregar campos TOTP a la entidad User y crear migración.
    2. Crear un servicio TotpService con generación/verificación de códigos y generación del URI otpauth://.
    3. Crear formularios y controladores para habilitar, verificar y deshabilitar 2FA.
    4. Registrar un EventSubscriber que intercepte peticiones y redirija a la verificación cuando corresponda.
    \n\n\n\n

    A continuación se muestran fragmentos clave (no es necesario copiar todo el archivo, adapte según su proyecto).

    \n\n\n\n

    Entidad: añadir campos para estado y secreto TOTP.

    \n\n\n\n
    <?php\n// src/Entity/User.php (fragmento)\n\n#[ORM\Column(name: 'totp_enabled', type: 'boolean', options: ['default' => false])]\nprivate bool $totpEnabled = false;\n\n#[ORM\Column(name: 'totp_secret', type: 'string', length: 64, nullable: true)]\nprivate ?string $totpSecret = null;\n\npublic function isTotpEnabled(): bool\n{\n    return $this->totpEnabled;\n}\n\npublic function setTotpEnabled(bool $enabled): self\n{\n    $this->totpEnabled = $enabled;\n    return $this;\n}\n\npublic function getTotpSecret(): ?string\n{\n    return $this->totpSecret;\n}\n\npublic function setTotpSecret(?string $secret): self\n{\n    $this->totpSecret = $secret ? trim($secret) : null;\n    return $this;\n}\n
    \n\n\n\n

    Migración: ejemplo que añade las columnas totp_enabled y totp_secret.

    \n\n\n\n
    <?php\n// migrations/Version20240101000000.php (fragmento)\n\npublic function up(Schema $schema): void\n{\n    $table = $schema->getTable('users');\n    if (!$table->hasColumn('totp_enabled')) {\n        $table->addColumn('totp_enabled', 'boolean', ['default' => false]);\n    }\n    if (!$table->hasColumn('totp_secret')) {\n        $table->addColumn('totp_secret', 'string', ['length' => 64, 'notnull' => false]);\n    }\n}\n
    \n\n\n\n

    Servicio TotpService: responsabilidades principales — generar secreto, generar/verificar códigos y crear URI de aprovisionamiento.

    \n\n\n\n
    <?php\n// src/Service/TotpService.php (fragmento)\n\npublic function generateSecret(int $length = 32): string\n{\n    $bytes = random_bytes($length);\n    return rtrim(strtr(base64_encode($bytes), '+/', 'XY'), '=');\n}\n\npublic function getProvisioningUri(string $label, string $issuer, string $secret): string\n{\n    $label = rawurlencode($label);\n    $issuerEncoded = rawurlencode($issuer);\n\n    return sprintf(\n        'otpauth://totp/%s?secret=%s&issuer=%s&period=%d&digits=%d&algorithm=%s',\n        $label,\n        $secret,\n        $issuerEncoded,\n        $this->period,\n        $this->digits,\n        strtoupper($this->algorithm)\n    );\n}\n\npublic function verifyCode(string $secret, string $code, int $window = 1): bool\n{\n    $now = time();\n    $code = trim($code);\n    for ($i = -$window; $i <= $window; $i++) {\n        $timestamp = $now + ($i * $this->period);\n        if (hash_equals($this->getCode($secret, $timestamp), $code)) {\n            return true;\n        }\n    }\n    return false;\n}\n
    \n\n\n\n

    Form types: formularios sencillos para habilitar y deshabilitar 2FA que aceptan el código de 6 dígitos.

    \n\n\n\n
    <?php\n// src/Form/User/TwoFactorEnableType.php (fragmento)\n\n$builder->add('code', TextType::class, [\n    'label' => 'Authentication code',\n    'attr' => [\n        'autocomplete' => 'one-time-code',\n        'inputmode' => 'numeric',\n        'pattern' => '[0-9]*',\n        'maxlength' => 6,\n    ],\n]);\n
    \n\n\n\n

    Controlador de ajustes: genera secreto temporal en sesión, muestra QR y confirma el código antes de persistir el secreto en la base de datos.

    \n\n\n\n
    <?php\n// src/Controller/User/SettingsController.php (fragmento)\n\n$pendingSecret = $session->get('2fa_pending_secret');\n// Regenerar si no existe o expiró\nif (!$pendingSecret || (time() - $session->get('2fa_pending_secret_time', 0)) > 600) {\n    $pendingSecret = $totpService->generateSecret();\n    $session->set('2fa_pending_secret', $pendingSecret);\n    $session->set('2fa_pending_secret_time', time());\n}\n\n$uri = $totpService->getProvisioningUri($user->getEmail(), $request->getHttpHost(), $pendingSecret);\n$qrSvg = $totpService->generateInlineSvgQr($uri, 180);\n
    \n\n\n\n

    Suscriptor de eventos: intercepta solicitudes y redirige a la ruta de verificación si el usuario tiene 2FA activado pero no ha verificado la sesión.

    \n\n\n\n
    <?php\n// src/EventSubscriber/UserTwoFactorSubscriber.php (fragmento)\n\nif (!$event->isMainRequest()) {\n    return;\n}\n\n$request = $event->getRequest();\nif (!str_starts_with($request->getPathInfo(), '/panel')) {\n    return; // limitar al panel de usuario\n}\n\n$user = $this->getAuthenticatedUser();\nif (!$user || !$user->isTotpEnabled() || !$user->getTotpSecret()) {\n    return;\n}\n\n$session = $this->getSession();\nif ($session && $session->get(self::SESSION_KEY) === true) {\n    return; // ya verificado\n}\n\n$event->setResponse(new RedirectResponse($this->urlGenerator->generate('user_2fa')));\n
    \n\n\n\n

    Seguridad en la configuración del firewall: redirigir al usuario a la ruta /panel/2fa tras el login es una opción sencilla para iniciar el flujo de verificación.

    \n\n\n\n
    security:\n    firewalls:\n        user:\n            pattern: ^/panel\n            provider: user_provider\n            lazy: true\n            form_login:\n                login_path: /panel/\n                check_path: /panel/\n                enable_csrf: true\n                default_target_path: /panel/2fa\n            logout:\n                path: /panel/logout\n                target: /panel/\n\n    access_control:\n        - { path: ^/panel/?$, roles: PUBLIC_ACCESS }\n        - { path: ^/panel, roles: IS_AUTHENTICATED_REMEMBERED }\n
    \n\n\n\n

    Protecciones adicionales sugeridas: limitación de intentos (rate limiting), comparación en tiempo constante (hash_equals) y manejo cuidadoso de sesiones y secretos temporales.

    \n\n\n\n
    <?php\n// Ejemplo de rate limiting dentro del controlador de verificación\n$limiter = $twoFactorLimiter->create($request->getClientIp());\nif (!$limiter->consume()->isAccepted()) {\n    throw new TooManyRequestsHttpException(null, 'Too many attempts. Please wait.');\n}\n
    \n\n\n\n

    Ejemplos

    \n\n\n\n

    Generar un URI de aprovisionamiento (otpauth) que puedan escanear las apps autenticadoras:

    \n\n\n\n
    // Uso en controlador\n$label = $user->getEmail();\n$issuer = $request->getHttpHost();\n$secret = $totpService->generateSecret();\n$uri = $totpService->getProvisioningUri($label, $issuer, $secret);\n$qrSvg = $totpService->generateInlineSvgQr($uri, 180);\n
    \n\n\n\n

    Verificar un código recibido del usuario (ventana de tolerancia = 1 período por defecto):

    \n\n\n\n
    // Verificación\nif ($totpService->verifyCode($storedSecret, $submittedCode)) {\n    // Aceptado: marcar sesión como verificada\n    $session->set('2fa_verified', true);\n} else {\n    // Código inválido\n}\n
    \n\n\n\n

    Checklist

    \n\n\n\n
    1. Agregar totp_enabled y totp_secret en la entidad y migrar.
    2. Registrar TotpService en el contenedor y probar generación/verificación localmente.
    3. Crear formularios y controladores para setup/disable/verify.
    4. Implementar EventSubscriber para forzar verificación tras el login.
    5. Configurar rate limiting y proteger rutas sensibles.
    6. Planificar recuperación: backup codes o proceso de soporte.
    \n\n\n\n

    Conclusión

    \n\n\n\n

    Implementar TOTP sin dependencias externas ofrece control y entendimiento del flujo de MFA. El patrón mostrado (servicio TOTP + suscriptor de eventos + verificación en sesión) es ligero y fácil de adaptar a requisitos adicionales como backup codes o WebAuthn.

    \n\n\n\n

    Priorice siempre: comparación en tiempo constante, limitación de intentos y proteger los secretos en reposo. Después de implementar, pruebe el flujo completo en entornos de staging antes de desplegar en producción.

    \n\n
  • Notificaciones PHP en tiempo real con Redis y WebSockets

    Notificaciones PHP en tiempo real con Redis y WebSockets

    Resumen: guía práctica para enviar notificaciones en tiempo real desde PHP usando Redis como bus de mensajes y WebSockets para entrega instantánea. Incluye ejemplo mínimo, buenas prácticas y checklist de despliegue.

    Introducción

    Las notificaciones en tiempo real son fundamentales para la experiencia de usuario moderna. En vez de pollings periódicos, una combinación de Redis (Pub/Sub o Streams) y un servidor WebSocket permite entregar mensajes al instante desde PHP.

    Prerrequisitos

    • PHP con soporte para ejecución de procesos permanentes (p. ej. Workerman, Swoole o Ratchet)
    • Redis (instancia accesible desde el servidor WebSocket)
    • Cliente Redis para PHP (Predis o phpredis) y composer
    • Clientes Web que soporten WebSockets y lógica de reconexión

    Desarrollo

    La arquitectura básica separa responsabilidades: la aplicación PHP publicará eventos en Redis; un proceso WebSocket suscrito a Redis retransmitirá esos mensajes a los clientes conectados.

    Procedimiento

    Pasos esenciales:

    1. Publicar un evento en Redis desde la app PHP cuando ocurre la acción (por ejemplo, comentario nuevo).
    2. El proceso WebSocket está suscrito al canal Redis y recibe el evento.
    3. El proceso WebSocket envía el payload a los clientes conectados (filtrando por usuario o canal si aplica).
    4. El cliente maneja el mensaje (mostrar notificación, solicitar detalles, marcar como leído, etc.).

    Ejemplo mínimo de servidor WebSocket en PHP usando Workerman y Predis (suscripción a Redis y broadcast a conexiones activas).

    <?php
    use Workerman\Worker;
    use Predis\Client as RedisClient;
    
    require 'vendor/autoload.php';
    
    $ws = new Worker("websocket://0.0.0.0:8080");
    $ws->count = 1;
    
    $redis = new RedisClient();
    
    $ws->onWorkerStart = function() use ($ws, $redis) {
        $pubsub = $redis->pubSubLoop();
        $pubsub->subscribe('notifications');
        foreach ($pubsub as $message) {
            if ($message->kind === 'message') {
                foreach ($ws->connections as $connection) {
                    $connection->send($message->payload);
                }
            }
        }
    };
    
    Worker::runAll();
    Lenguaje del código: PHP (php)

    Este proceso mantiene una conexión permanente a Redis y distribuye cada mensaje recibido a todas las conexiones WebSocket. En producción conviene no enviar todo el payload a todos los clientes: filtrar por canal/usuario.

    Ejemplo de publicación de un evento desde la aplicación PHP usando Predis.

    <?php
    use Predis\Client as RedisClient;
    
    $redis = new RedisClient();
    
    $event = json_encode([
        'type' => 'comment_created',
        'user_id' => 42,
        'data' => ['id' => 123, 'excerpt' => 'Nuevo comentario']
    ]);
    
    $redis->publish('notifications', $event);
    Lenguaje del código: PHP (php)

    En el ejemplo anterior publicamos en un canal genérico ‘notifications’. Para evitar sobre-broadcasting, use canales por usuario o por topic (p. ej. notifications:user:42).

    Ejemplos

    Cliente JavaScript: conexión WebSocket básica con reconexión y manejo de mensajes ligeros (solo resumen; adapte según su app).

    function createSocket(url) {
      let ws;
      let retry = 1000;
    
      function connect() {
        ws = new WebSocket(url);
    
        ws.onopen = () => {
          retry = 1000; // reset backoff
          console.log('WS connected');
        };
    
        ws.onmessage = (ev) => {
          const msg = JSON.parse(ev.data);
          // manejar evento: mostrar notificación o solicitar detalles
          console.log('evento', msg);
        };
    
        ws.onclose = () => {
          console.log('WS closed, reconnecting in', retry);
          setTimeout(connect, retry);
          retry = Math.min(30000, retry * 2);
        };
    
        ws.onerror = (err) => {
          console.error('WS error', err);
          ws.close();
        };
      }
    
      connect();
      return () => ws && ws.close();
    }
    
    // uso
    const stop = createSocket('wss://example.com:8080');
    Lenguaje del código: JavaScript (javascript)

    Consejo: mantenga los payloads ligeros. Enviar solo el ID del evento o un resumen reduce latencia y consumo de ancho de banda.

    Redis + WebSockets transforman un backend PHP tradicional en un canal de notificaciones cercano a tiempo real, sin necesidad de reescrituras completas.

    Checklist

    1. Usar canales por usuario o topic para evitar sobre-broadcast.
    2. Autenticar y autorizar suscripciones (gateway o tokens JWT).
    3. Implementar reconexión y reintentos en cliente.
    4. Considerar Redis Streams si necesita persistencia y replay de mensajes.
    5. Monitoreo del proceso WebSocket y alertas para reinicio automático.
    6. Limitar tamaño del payload y evitar enviar datos sensibles por el socket.

    Conclusión

    Combinar Redis y WebSockets permite a aplicaciones PHP ofrecer notificaciones instantáneas sin depender de polling. El patrón reduce latencia y escala bien si se aplica filtrado por canales, autenticación y manejo de fallos.

    Empiece con un prototipo mínimo (un proceso WebSocket suscrito a Redis) y evolucione a Streams, balanceo y autenticación según las necesidades de producción.

  • PHP vs Node.js: cómo elegir el backend en 2025

    PHP vs Node.js: cómo elegir el backend en 2025

    Resumen: Comparativa técnica entre PHP y Node.js para elegir backend según requisitos de rendimiento, ecosistema y experiencia del equipo.

    Este artículo sintetiza ventajas, limitaciones y ejemplos mínimos para ayudar a arquitectos y desarrolladores a decidir qué tecnología usar.

    Introducción

    PHP y Node.js son tecnologías maduras para backend con enfoques distintos: PHP tradicionalmente síncrono y orientado a request-response; Node.js basado en I/O asíncrono y event-driven.

    Prerrequisitos

    Antes de elegir, evalúa: cargas concurrentes previstas, necesidad de tiempo real, experiencia del equipo y requisitos de despliegue.

    1. Definir el patrón de tráfico (p. ej. muchas conexiones concurrentes vs pocas por usuario).
    2. Identificar dependencias y ecosistema (CMS, bibliotecas, integraciones).
    3. Revisar capacidades de hosting y costos operativos.

    Desarrollo

    Comparar en cuatro ejes: rendimiento, ecosistema, curva de aprendizaje y despliegue.

    Procedimiento

    1) Analiza el caso de uso. 2) Mide concurrencia y latencia objetivo. 3) Selecciona la pila que minimice riesgos técnicos y de operación.

    Resumen de diferencias clave:

    • PHP: buen soporte para sitios de contenido, despliegue sencillo en hosting compartido, amplio ecosistema (WordPress, Composer, Laravel).
    • Node.js: mejor para I/O intensivo y tiempo real; ecosistema moderno con npm y frameworks como Express o Fastify.

    Ejemplos

    Ejemplos mínimos que ilustran el modelo de ejecución en cada plataforma.

    <?php
    // Ejemplo PHP: manejador básico en entorno tradicional (request-response)
    header('Content-Type: application/json');
    $response = ['time' => date('c'), 'message' => 'Hola desde PHP'];
    echo json_encode($response);
    Lenguaje del código: PHP (php)

    En PHP el ciclo típico abre, procesa y cierra la petición; es sencillo y efectivo para sitios de contenido.

    const http = require('http');
    
    const server = http.createServer((req, res) => {
      res.writeHead(200, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify({ time: new Date().toISOString(), message: 'Hola desde Node.js' }));
    });
    
    server.listen(3000, () => {
      console.log('Server listening on port 3000');
    });
    Lenguaje del código: JavaScript (javascript)

    Node.js mantiene un loop de eventos que permite gestionar muchas conexiones concurrentes con eficiencia en I/O.

    Checklist

    Lista rápida para decidir tecnología según el proyecto.

    1. ¿El proyecto requiere tiempo real o muchas conexiones concurrentes? → Considerar Node.js.
    2. ¿Priman CMS o contenidos estáticos y despliegue rápido? → PHP/WordPress puede ser suficiente.
    3. ¿El equipo domina JavaScript o PHP/Laravel? → Elegir según experiencia para reducir riesgos.
    4. ¿Necesitas microservicios o arquitectura basada en eventos? → Node.js suele facilitarlo.

    Conclusión

    No existe una respuesta universal: PHP sigue siendo válido para sitios de contenido y despliegues rápidos; Node.js destaca en aplicaciones en tiempo real y arquitecturas orientadas a I/O.

    La recomendación práctica: prioriza requisitos técnicos, experiencia del equipo y costos operativos al seleccionar entre PHP y Node.js.

  • Evolución de las colas en Laravel: workers, deferred y background

    Evolución de las colas en Laravel: workers, deferred y background

    Este artículo resume la evolución del sistema de colas en Laravel: desde los workers tradicionales hasta el driver background basado en concurrencia. Explica usos, diferencias y ejemplos prácticos de implementación.

    Introducción

    Laravel ha transitado de un sistema de colas basado en workers persistentes a opciones que reducen la complejidad operativa: drivers deferred y background (impulsado por concurrencia).

    Prerrequisitos

    Antes de aplicar cualquiera de las estrategias descritas, confirma lo siguiente:

    • Proyecto Laravel con entorno PHP configurado.
    • Driver de colas definido (Redis, database, etc.) si planeas usar workers tradicionales.
    • En caso de background driver, la configuración de conexiones en config/queue.php debe incluir la conexión ‘background’ (ver ejemplo).

    Desarrollo

    Procedimiento

    A continuación se describen las tres aproximaciones principales y cómo elegir entre ellas según la carga y la tolerancia a fallos.

    1. Workers tradicionales: ejecutan jobs mediante procesos persistentes (p. ej. php artisan queue:work redis), adecuados para cargas pesadas y con control avanzado de reintentos y fallos.
    2. Driver deferred: ejecuta el job después de enviar la respuesta HTTP, sin worker. Adecuado para tareas ligeras y no críticas.
    3. Driver background (concurrencia): ejecuta jobs en procesos PHP separados, sin worker persistente; equilibrio entre robustez y simplicidad operativa.

    Ventajas y limitaciones resumidas:

    • Workers tradicionales: alto rendimiento y control; requieren DevOps para gestionar procesos.
    • Deferred: baja sobrecarga; limitado en reintentos y duración de tarea.
    • Background: sin workers dedicados, más robusto que deferred; útil para tareas de duración media.
    php artisan queue:work redis
    Lenguaje del código: Bash (bash)
    <?php
    return [
        'connections' => [
            'background' => [
                'driver' => 'background',
            ],
        ],
    ];
    Lenguaje del código: PHP (php)

    El ejemplo anterior muestra cómo declarar una conexión ‘background’ en config/queue.php. Su dispatch usa la conexión para ejecutar el job en otro proceso PHP.

    Ejemplos

    Ejemplo de clase Job que implementa ShouldQueue y se serializa para su ejecución en background o por un worker.

    <?php
    namespace App\Jobs;
    
    use Illuminate\Bus\Queueable;
    use Illuminate\Contracts\Queue\ShouldQueue;
    use Illuminate\Foundation\Bus\Dispatchable;
    use Illuminate\Queue\SerializesModels;
    
    class RecordDelivery implements ShouldQueue
    {
        use Dispatchable, Queueable, SerializesModels;
    
        public function __construct(public $order)
        {
        }
    
        public function handle()
        {
            // lógica de procesamiento
        }
    }
    Lenguaje del código: PHP (php)

    Dispatch desde un controlador usando la conexión background para evitar bloquear la petición HTTP.

    <?php
    use App\Jobs\RecordDelivery;
    
    class DeliveryController
    {
        public function store(Request $request)
        {
            $order = Order::create([...]);
            RecordDelivery::dispatch($order)->onConnection('background');
    
            return response()->json(['status' => 'processing'], 202);
        }
    }
    Lenguaje del código: PHP (php)

    Checklist

    1. Determina la criticidad de la tarea (alta → worker tradicional).
    2. Si la tarea es ligera y no crítica, considera deferred.
    3. Para equilibrio operativo (sin workers pero más robusto que deferred), usa el driver background.
    4. Configura reintentos, timeouts y monitoreo según el método elegido.

    Conclusión

    La evolución de las colas en Laravel ofrece alternativas para distintos perfiles de carga operativa. Elegir entre workers, deferred o background depende de la carga, la tolerancia a fallos y la capacidad operativa del equipo.

    Si buscas simplificar la operación sin renunciar a capacidad de procesamiento, el driver background —impulsado por concurrencia— es una opción intermedia interesante.

  • Go y PHP: cómo diseñar un sistema híbrido eficiente

    Go y PHP: cómo diseñar un sistema híbrido eficiente

    Este artículo describe una aproximación práctica para integrar Go y PHP en un sistema híbrido: cuándo delegar tareas, cómo comunicar microservicios y cómo desplegar con Docker.

    Incluye arquitectura, retos comunes, ejemplos de código (PHP, servicio en Go, Dockerfiles, docker-compose) y una checklist para implementación.

    Introducción

    Cuando una aplicación PHP comienza a mostrar cuellos de botella por procesamiento concurrente o tareas CPU-intensivas, una reescritura completa puede ser costosa y arriesgada.

    Una alternativa es un diseño híbrido: conservar PHP para la interfaz web y operaciones CRUD habituales, y delegar a Go las tareas de alto rendimiento y concurrencia.

    Prerrequisitos

    Antes de implementar la integración, confirma lo siguiente en tu entorno:

    • Servicio PHP con cliente HTTP (ej.: Guzzle) y ORM para la base de datos.
    • Servicio Go independiente para procesamiento concurrente.
    • Contenerización con Docker para ambos servicios y orquestación mínima (docker-compose o similar).
    • Definición clara de API (endpoints, formatos JSON, timeouts y reintentos).

    Desarrollo

    La pieza clave es separar responsabilidades y diseñar una comunicación eficiente entre servicios para evitar latencias y fallos de cascada.

    Arquitectura recomendada: microservicios independientes que intercambian JSON vía HTTP/REST. PHP se queda con las rutas web y consultas habituales; Go procesa trabajos intensivos y responde de forma asíncrona cuando sea pertinente.

    Procedimiento

    Pasos prácticos para integrar ambos servicios en producción:

    1. Identificar rutas y operaciones CPU-intensivas o altamente concurrentes que se puedan delegar a Go.
    2. Definir API REST clara entre PHP y Go con contrato JSON, códigos de estado y manejo de errores.
    3. Implementar timeouts y reintentos en el cliente HTTP de PHP; evitar bloquear las peticiones de usuario por procesos largos.
    4. Contenerizar ambos servicios y usar orquestación para escalado independiente.
    5. Monitorear latencia, errores y uso de recursos; ajustar goroutines y límites de concurrencia en Go.

    En entornos donde la respuesta inmediata no es requerida, considera que Go inicie el trabajo de forma asíncrona y devuelva un estado “aceptado” para que PHP continúe sin bloqueo.

    Ejemplos

    A continuación hay ejemplos extraídos de un caso real: cliente PHP (Guzzle), servicio en Go, Dockerfiles y docker-compose.

    Ejemplo: llamada desde PHP usando Guzzle (manejar timeout y convertir la respuesta JSON).

    <?php
    use GuzzleHttp\Client;
    $client = new Client();
    $response = $client->post('http://go-service/api/process', [
        'json' => ['data' => $data],
        'timeout' => 5,
    ]);
    $processedData = json_decode($response->getBody()->getContents(), true);
    Lenguaje del código: PHP (php)

    Servicio Go: endpoint que acepta JSON y lanza el procesamiento de forma concurrente. (Se muestra como texto plano para mantener compatibilidad del bloque.)

    package main
    import (
        "encoding/json"
        "fmt"
        "net/http"
        "time"
    )
    
    type RequestData struct {
        Data string `json:"data"`
    }
    
    func processData(w http.ResponseWriter, r *http.Request) {
        var reqData RequestData
        decoder := json.NewDecoder(r.Body)
        if err := decoder.Decode(&reqData); err != nil {
            http.Error(w, err.Error(), http.StatusBadRequest)
            return
        }
        go func(data string) {
            time.Sleep(2 * time.Second) // Simula procesamiento
            fmt.Println("Processed data:", data)
        }(reqData.Data)
        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusOK)
        json.NewEncoder(w).Encode(map[string]string{"status": "processing started"})
    }
    
    func main() {
        http.HandleFunc("/api/process", processData)
        http.ListenAndServe(":8080", nil)
    }
    Lenguaje del código: texto plano (plaintext)

    Dockerfile para el servicio PHP (ejemplo presente en la referencia):

    FROM php:8.0-apache
    COPY . /var/www/html/
    RUN docker-php-ext-install pdo pdo_mysql
    EXPOSE 80
    Lenguaje del código: Dockerfile (dockerfile)

    Dockerfile para el servicio Go (ejemplo presente en la referencia):

    FROM golang:1.19-alpine
    WORKDIR /app
    COPY . .
    RUN go build -o go-service
    CMD ["./go-service"]
    EXPOSE 8080
    Lenguaje del código: Dockerfile (dockerfile)

    docker-compose para levantar ambos servicios juntos:

    version: '3'
    services:
      php-service:
        build:
          context: ./php
        ports:
          - "8081:80"
      go-service:
        build:
          context: ./go
        ports:
          - "8080:8080"
    Lenguaje del código: YAML (yaml)

    Checklist

    1. Detectar operaciones costosas y definir contratos API para delegarlas.
    2. Implementar timeouts, reintentos y manejo de errores en PHP.
    3. Contenerizar servicios y configurar orquestación para escalado independiente.
    4. Monitorizar latencia, uso de CPU/memoria y ajustar concurrencia en Go.
    5. Probar fallos en la comunicación y definir fallbacks razonables en PHP.

    Conclusión

    Un enfoque híbrido Go + PHP permite aprovechar lo mejor de cada lenguaje sin rehacer todo el sistema. La clave es separar responsabilidades, diseñar APIs robustas y automatizar despliegues.

    Si decides seguir esta ruta, prioriza pruebas de integración, políticas de reintento y observabilidad para minimizar impactos en la experiencia de usuario.